3章　アラート、オンコール、インシデント管理

作成日: 2024/7/9

最終更新日: 2024/7/15

「監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。」

アラートは、この目的を達成するための1つの方法でしかない

素晴らしいアラートは、見た目よりも難しい

この章では、より良いアラートを作るためのヒント、オンコールの辛さと苦しさ、インシデント管理と障害の振り返りを取り上げる

3.1 どうしたらアラートをよくできるか

アラートは、コンテキストによっての2つの意味で使われる。

①誰かを叩き起こすためのアラート

緊急の対応が必要、対応しないとシステムダウンしてします

電話、テキストメッセージ、アラームなど

e.g. 全Webサーバーがダウンした、メインサイトへの疎通が取れない...

②参考情報 (FYI) としてのアラート

すぐに対応する必要はない

アラートがきたことは誰かが確認すべき

e.g. 夜間バックアップが失敗した

後者のアラートは事実上アラートではなく、単なるメッセージ。

ここ (本) では、前者について取り上げる。

それ以外の情報は、ログ、社内のチャットルームのメッセージ、チケットの自動生成などの形式になる。

→ なるほど、「社内のチャットルームのメッセージ」にアラートを送っているが、「傾向を知る」ような使い方しちゃってるのだめそう？だなあ... と思っていたけど、「社内のチャットルームのメッセージ」に送っているので、「②参考情報 (FYI) としてのアラート」と捉えて、それはそれで良さそうだな。

良いアラートの仕組みを作る6つの方法:

アラートにメールを使うのをやめよう

手順書を書こう

固定の閾値を決めることだけが方法ではない

アラートを削除し、チューニングしよう

メンテナンス期間を使おう

まずは自動復旧を試そう

3.1.1 アラートにメールを使うのをやめよう

メールは誰かを叩き起こすためのものではないし、そのために使おうと思うべきものでもない。

メールでアラートを送るのは、受け取る人がうるさくて最もうんざりしてしまう方法。

アラート疲れの原因になる。

アラートの使い道:

すぐに応答かアクションが必要なアラート

SMS、PagerDuty などのページャーに送る

この本の定義でいう本来のアラート

注意が必要だがすぐにアクションは必要ないアラート

社内のチャットルームに送る

→ これだこれだ

履歴や診断のために保存しておくアラート

ログファイルに送る

→ うん、これもやってるな

アラートのログを取る:

アラートのログを保存しておいて、後でレポートを送れるようにしておくのは重要

→ 「アラートのログ」って？ログファイルに送った「履歴や診断のために保存しておくアラート」のこと？

アプリケーションやサービスのどの部分でトラブルが多く、どこに改善の焦点を合わせればよいのか分かる

→ ほしい。具体的にどんなレポートになるんだろう？

SLAをレポートするのにも役立つ

3.1.2 手順書を書こう

手順書 (runbook) は、アラートが来た時にすばやく自分の進むべき方向を示す素晴らしい方法。

環境が複雑になって来るとチームのだれもが各システムのことを知っているわけではなくなる。

知識を広めるよい方法になる。

よい手順書とは、特定のサービルについて以下のような質問に答えるように書かれたもの:

これは何のサービスで、何をするものか

誰が責任者であるか

どんな依存性を持っているか

インフラの構成はどのようなものか

どんなメトリクスやログを送っていて、それらはどういう意味なのか

どんなアラートが設定されていて、その理由は何なのか

→ あああ、これはあると/あったらすっごく助かる/助かっただろうなあ... 自分が開発に入ってなくて保守運用から入ると、本当にわからないからなあ... アラートあがって初めて「そんな機能あったんですか、お初にお目にかかります」みたいになる

各アラートには、対象サービスの手順書へのリンクを入れましょう

何が起こっているか

アラートがどんな意味か

修復の手順

→ これはやりたい。が、手順通りに解決していくようなアラート、何かあったかなあ... 我々のシステムは、まだそこまで定型化していないような...

手順書は、何らかの問題を解決するのに、人間の判断と診断が必要な時のためのもの

→ 本当にそうだなあ。アラートに限らず、そうしたいよ。そうしたいけど、工数がとれないときもある。けど全面的にそうしたい。とても賛成。

→ ちなみに、付録Aに手順書の例がついている。読んだところ、我々のプロジェクトでも、それぞれページは独立しているものの、書いている項目まあまああった。項目の内容は各ページへのリンクで良いので、1ページにまとめるのも良さそうだ。まずそこを見る、のような立ち位置の。

「アラート」の、「アラートがどんな時に発報されるか」は書いているけれど、「原因として考えられること」「xxx か ooo に問題がないか確認してください」は書いていないので、書きたい。

3.1.3 固定の閾値を決めることだけが方法ではない

アラートの基準に固定の閾値を決めるのは間違い

警告、致命的といった状態がどんな状況でも当てはまるわけではない

e.g. ディスク空き容量が10%以下

ディスク使用量が11%から80%まで急激に増えるケースを見逃してしまう

本当に知らせてほしいのはこういうケース

固定の閾値だとアラートが送られない

-> 「一晩でディスク使用量が50%増加」をアラートする

変化量、グラフの傾きを使う

移動平均、信頼区間、標準偏差などある程度の統計情報を使う

3.1.4 アラートを削除し、チューニングしよう

「アラート疲れ」を引き起こす、監視システムを信用しなくなる、無視してしまうようになるのは良くない

対策は、アラートの量を減らす、アラートのノイズを減らす

減らす方法

1. 誰かがアクションする必要がある状態か？

2. 1ヶ月のアラート履歴を見て、監視の内容をより正確にするようデザインし直す

どんなアラートがあるか

どんなアクションをとったか

各アラートの影響はどうだったか

削除してしまえるアラートはないか

3. アラートを削除するために、どんな自動化の仕組みが作れるか

3.1.5 メンテナンス期間を使おう

何らかの作業をする必要があり、その作業を実施するとアラートがあがることがあらかじめわかっている場合は、アラートを止めておく (アラートをメンテナンス期間に入れる)

ただし、止め過ぎ注意

知らなかった依存性に気づけたり、メンテナンス作業が意図しない影響を及ぼしていることを知ったりできるので、あんまり広範囲に止め過ぎないように

3.1.6 まずは自動復旧を試そう

アラートに対する代表的なアクションが、基地でかつ用意されたドキュメントの手順に沿って対応するだけなら、コンピューターにやらせる == 自動復旧

→ ECS のターゲット追跡スケーリングポリシーなどそうだなあ

今ECSサービスのCPUとメモリのアラートも入れているけれど、何だったらそっちはいらないのかも...

ECS のターゲット追跡スケーリングポリシーで、CPUとメモリでオートスケールアウト/インを入れているので

タスク数の増減のほうをアラート？

でもスケジュールされたスケーリングも設定してたらどうなるんでしょうね？

いやこっちもアラート来ていいのかな..

というか、Mackerelの監視ルールの種類もっとたくさんあるのに、使いこなせてない

標準化された復旧手順をコードとして実装して、人間に通知する代わりに監視システムにそれを実行させる

自動復旧によって問題が解決できないときに、アラートを送る

3.2 オンコール

オンコールとは ... 何か問題が起きたという呼び出しに答えられるようにしている担当のこと

夜中にコンピューターがおかしいな動作をしないようにはできないが、その正で必要ないのに叩き起こされることがないようにはできる

3.2.1 誤報を修正する

100%成果なアラートを実現するのは非常に難しい、無理だけれども、誤報をかなりの量まで減らすことはできる

オンコールの人が、

前日に送られたすべてのアラート一覧を作る

改善、削除する

毎回繰り返す

3.2.2 無用の場当たり的対応を減らす

「監視自体は何も修復してくれません。何かが壊れたら、あなたがそれを直す必要があります。」

場当たり的対応をやめるためには、その基礎にあるシステムを改善するのに時間を使おう。

→ すごく正論なんだけど、予算の都合で、問題も解決方法もわかってるのに改修させてもらえない場合もあり... (泣)

海外は知らないけれど、日本企業では、保守運用をなるべく低コストで済ませたい → 改修する費用出さない → 今いる保守運用メンバーのマンパワーでどうにかして、というケースがある

この習慣を身につける2つの効果的な戦略

オンコールシフト中、場当たり的対応をしていない時間は、システムの回復力や安定性に対して取り組むのをオンコール担当の役割にする。

前週のオンコールの際に収集した情報を元に、次の週のスプリント計画やチーム会議の際にシステムの回復性や安定性について取り上げる計画を立てる

→ これ良さそうだな、レトロで振り返る → スプリントプランニングで計画する、ちょこちょこ作業日でちょっとやる、とか

3.2.3 上手にオンコールローテーションを組む

常にオンコール担当でいるのは、人を燃え尽きさせる最善の方法

オンコールはローテーションすべし

おすすめ:

4メンバーだったら、1週間交代、4週単位、間を3週間空ける

カレンダーの週に合わせるのではなく、出勤日にオンコールのローテーションを始める

チーム内でオンコールの引き継ぎができるように

水曜午前10時交代

それなりに大きさのチームでない限り、ほとんどの場合、バックアップのオンコール担当は必要ない (筆者は考えている)

しょっちゅう担当が回ってきて負荷になるため

エスカレーションパス

オンコール担当がひとりぼっちにならないように。オンコール担当が解決できないことに対してエスカレーションできるパス。

ソフトウェアエンジニアもオンコールのローテーションに入れる

丸投げを避ける、よりよいソフトウェアを作ろうというインセンティブが生まれる。

ソフトウェアエンジニアと運用エンジニアの間に、お互いの共感が強まる

→ 作るだけ作ってあとは知らない、困ったことは運用エンジニアに押し付けるー、は良くないよね、生産的じゃない

ツールを使用することをおすすめ

オンコールの仕組みを強化できる

エスカレーションパス、スケジュール構築運用、レビュー、インシデント自動記録

e.g. PagerDuty、VictorOps、OpsGenie

Follow-the-Sun (対応を追いかける) ローテーション

オンコールに対する補償

オンコールのあとは、有給休暇1日取らせる

神経使うので、回復のための日を確保する価値ある

手当も払う

3.3 インシデント管理

インシデント管理とは ... 発生した問題を扱う正式な手順のこと

ITIL から来たもの

インシデントの認識と対応に関する正式で一貫した方法があることで、チームには一定の厳格さと規律が生まれる

インシデントのプロセス

1. インシデントの認識 (監視が問題を認識)

2. インシデントの記録 (インシデントに対して監視の仕組みが自動でチケットを作成)

→ ふむう、なるほど

3. インシデントの診断、分類、解決、クローズ (オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みにする)

4. 必要に応じて、問題発生中にコミュニケーションを取る

5. インシデント解決後、回復力を高めるための改善策を考える

インシデントを扱う正式な手順である社内標準として、インシデント対応を決めることには十分な価値がある

インシデントのログが残され、一貫性を持って追跡調査される

ユーザー、経営者、顧客が透明性を持って情報を受け取り、何が起こっているか知れる

チームがアプリケーションとインフラにどんなパターンで問題があるか、どこで問題が起きやすいかを知れる

→ ふむ、なんとなく上記のような感じでやってるけど、明文化すると良いかも

インシデント時の役割

数分以上かかるサービスの停止を伴うインシデントの場合、明確に定義された役割が重要

それぞれの役割は1つの機能が割り当てられ、2つ以上の兼務は避けるべき

インシデント管理の各役割は、通常時のチームでの役割といっしょである必要はない

1. 指揮官 (IC、incident commander)

決断する役割

改善、顧客や社内とのコミュニケーション、調査にはかかわらない

サービス停止に関する調査を監督する

(ふだんは) エンジニアの役割をやっているひとがおすすめ

リスクとトレードオフを評価するのに最適な人 ≒ エンジニア、が決断する役割を担える

2. スクライブ (scribe)

書記の役割

起こったことを記録していく

誰が何をいつ行ったのか、どんな決断がされたのか、どんなフォローアップすべき項目が見つかったのか

調査や改善は行わない

3. コミュニケーション調整役 (communication liaison)

社内外問わず利害関係者に最新状況のコミュニケーションを取る役割

唯一のコミュニケーションエンドポイント

利害関係者 (経営者など) が、インシデントの解決に取り組んでいるひとたちに最新情報を直接聞いてしまってインシデント解決を邪魔しないようにする

(ふだんは) チームのマネージャーの役割をやっているひとがおすすめ

割り込みからチームを守る

4. SME (subject matter expert)

実際にインシデント対応する人

→ 自然と上記のような感じで役割分担して進めるけれど、明確に宣言して進めるともっとスムーズかもしれないな、と思った。チームにも顧客にも。

「利害関係者 (経営者など) が、インシデントの解決に取り組んでいるひとたちに最新情報を直接聞いてしまってインシデント解決を邪魔」する、のはありがち。インシデント解決もコミュニケーションも中途半端になっちゃって、進みが遅くなる。

明確に専任の「コミュニケーション調整役」をたてれば、そのあたり、チームにとっても利害関係者にとってもハッピーそう。

3.4 振り返り

インシデントが発生した後は、インシデントに関する議論 (何が起きたのか、なぜ起きたのか、どうやって修正したのか等) の場を常に設けるべき

→ おう、「場を設ける」はやってないかも..？いや、スプリントレビュー (やPMO？) で話してるからそれでいいのかな。でも「議論」はほとんどしてないな...？

振り返りの場は、原則的に、利害関係のあるすべての組織から人を集め、何が問題で、なぜ発生して、再発防止のためにチームでどう対応していくのかを議論しましょう。

→ これやると良さそう

振り返りの良くない習慣

誰かを非難する文化

ミスした人が罰せられる、問題を覆い隠さざるを得ないような雰囲気

ミスに対する罰や恥を恐れている人は、それを隠したり軽視したりするはず

インシデント発生後の対応が誰かを避難するものになるなら、内部に潜む本当の問題を改善することは絶対にできない

→ 「国際民間航空機関（ICAO）が定めた国際民間航空条約第13付属書（ICAO Annex13）」を思い出した。

3.5 まとめ

アラートは難しいけれど、いくつかのヒントを活用することで正しい方向に進めます。

アラートをメールで送らないようにしよう。

手順書を書こう。

すべてのアラートがシンプルな閾値で決められるわけではない。

常にアラートを見直そう。

メンテナンス期間を使おう。

誰かにアラートを送る前に自動復旧を試そう。

いくつかの方法を使えば、オンコールの仕組みを改善するのは難しくありません。

自社にあったシンプルで使い道のあるインシデント管理プロセスを作るのを優先しよう。